Stability in Weak Memory Models

Concurrent programs running on weak memory models exhibit relaxed behaviours, making them hard to understand and to debug. To use standard verification techniques on such programs, we can force them to behave as if running on a Sequentially Consistent (SC) model. Thus, we examine how to constrain the behaviour of such programs via synchronisation to ensure what we call their stability, i.e. that they behave as if they were running on a stronger model than the actual one, e.g. SC. First, we define sufficient conditions ensuring stability to a program, and show that Power’s locks and read-modify-write primitives meet them. Second, we minimise the amount of required synchronisation by characterising which parts of a given execution should be synchronised. Third, we characterise the programs stable from a weak architecture to SC. Finally, we present our offence tool which places either lock-based or lock-free synchronisation in a x86 or Power program to ensure its stability. Concurrent programs running on modern multiprocessors exhibit subtle behaviours, making them hard to understand and to debug: modern architectures (e.g. x86 or Power) provide weak memory models, allowing optimisations such as instruction reordering, store buffering or write atomicity relaxation [2]. Thus an execution of a program may not be an interleaving of its instructions, as it would be on a Sequentially Consistent (SC) architecture [18]. Hence standard analyses for concurrent programs might be unsound, as noted by M. Rinard in [25]. Memory model aware verification tools exist, e.g. [24, 11, 15, 30], but they often focus on one model at a time, or cannot handle the write atomicity relaxation exhibited e.g. by Power: generality remains a challenge. Fortunately, we can force a program running on a weak architecture to behave as if it were running on a stronger one (e.g. SC) by using synchronisation primitives; this underlies the data race free guarantee (DRF guarantee) of S. Adve and M. Hill [3]. Hence, as observed e.g. by S. Burckhart and M. Musuvathi in [12], “we can sensibly verify the relaxed executions [. . . ] by solving the following two verification problems separately: 1. Use standard verification methodology for concurrent programs to show that the [SC] executions [. . . ] are correct. 2. Use specialized methodology for memory model safety verification”. Here, memory model safety means checking that the executions of a program, although running on a weak architecture, are actually SC. To apply standard verification techniques to concurrent programs running on weak memory models, we thus first need to ensure that our programs have a SC behaviour. S. Burckhart and M. Musuvathi focus in [12] on the Total Store Order (TSO) [28] memory model. We generalise their idea to a wider class of models (defined in [5], and recalled in Sec. 1): we examine how to force a program running on a weak architecture A1 to behave as if running on a stronger one A2, a property that we call stability from A1 to A2. To ensure stability to a program, we examine the problem of placing lock-based or lock-free synchronisation primitives in a program. We call synchronisation mapping an insertion of synchronisation primitives (either barriers (or fences), read-modify-writes, or locks) in a program. We study whether a given synchronisation mapping ensures stability to a program running on a weak memory model, e.g. that we placed enough primitives in the code to ensure that it only has SC executions. D. Shasha and M. Snir proposed in [27] the delay set analysis to insert barriers in a program, but their work does not provide any semantics for weak memory models. Hence questions remain w .r .t . the adequacy of their method in the context of such models. On the contrary, locks allow the programmer to ignore the details of the memory model, but are costly from a compilation point of view. As noted by S. Adve and H.-J. Boehm in [4], “on hardware that relaxes write atomicity [e.g. Power], it is often unclear that more efficient mappings (than the use of locks) are possible; even the fully fenced implementation may not be sequentially consistent.” Hence not only do we need to examine the soundness of our synchronisation mappings (i .e. that they ensure stability to a program), but also their cost. Thus, we present several new contributions: 1. We define in Sec. 2 sufficient conditions on synchronisation to ensure stability to a program. As an illustration, we provide in Sec. 3 semantics to the locks and readmodify-writes (rmw) of the Power architecture [1] (i .e. to the lwarx and stwcx. instructions) and show in Coq that they meet these conditions. 2. We propose along the way several synchronisation mappings, which we prove in Coq to enforce a SC behaviour to an x86 or Power program. 3. We optimise these mappings by generalising in Sec. 4 the approach of [27] to weak memory models and both lock-based and lock-free synchronisation, and characterise in Coq the executions stable from a weak architecture to SC. 4. We describe in Sec. 5 our new offence tool, which places either lock-based or lockfree synchronisation in a x86 or Power assembly program to ensure its stability, following the aforementioned characterisation. We detail how we used offence to test and measure the cost of our synchronisation mappings. We formalised our results in Coq; we omit the proofs for brevity. A long version with proofs, the Coq development, the documentation and sources of offence and the experimental details can be found at http://offence.inria.fr.